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The Society has, for a number of years, been actively studying the appli- 
cation of computer technology to our curatorial record system. Properly 
developed, the data base would have significant application in two im- 
portant areas: greater and more efficient use of our collections for re- 
search purposes and far better inventory control over our collections than 
now exists. 

For some time the sheer size of the projected data base constituted a 
formidable obstacle to progress. A large-scale computer seemed indicated. We 
were discouraged at the high on-going costs, the necessity to adapt our in- 
formation neéds to existing programs and the cumbersome procedures for getting 
data into and out of the remote computer facility. 

However in the fall of 1978, Mr. Bass initiated discussions between 
the staff and a Dallas-based data processing consultant firm, The Corporation 
for Distributed Systems (CDS), with regard to the feasibility of a wholly- 
owned, in-house system to meet the Society's needs. These conferences led 
to a consultantship contract with CDS under which we defined our research 
and inventory control requirements and CDS developed a hardware/software 
configuration to meet these needs within a realistic budget. 

In July 1979, CDS issued their consultant's report in the form of a 
proposal recommending acquisition by the Society of an in-house computer 
Paaativw, Bill Metcalf and I have reviewed the proposal in depth. We have 
discussed the content of the report in great detail with its author, Skip 
Hill of CDS. In addition we submitted the proposal to Hans Rutimann, Director 


of Data Processing Services at the Modern Language Association, and to Bill 


Pollock who developed the program used by the Museum of the American Indian 
to place the record of its entire collection on computer. 

Both Rutimann and Pollock uepréased admiration for Hill's proposed solution 
to our collection management problem. Each ies indi peked that the hardware/ 
software configuration outlined in the report is feasible and ieibalively 
Raacoloed: Both have also made Suikeatinae which have been discussed with 
Hill and have aided me in developing the acquisition and operating budgets. 

In February Bill and I visited the Axxess Corp. in Mountainside, N.J., 
the company proposed as the OEM by Hill, Axxess has the desired hardware/ 
software configuration, based on the PRIME 400 CPU and 300 MB disk drive, 
with other peripherals by independent manufacturers, which Hill proposes for 
the ANS. Hill would, of course, modify "information management" programs to 
suit our particular needs. 

While at Axxess, we discussed a number of points relating to the perfor- 
mance of the proposed peripheral equipment and had demonstrated to us some of 
the key input and tnqutty procedures so that we could better appreciate the 
processes described in Hill's proposal and evaluate the time and labor in- 
volved in these steps. Hill has proposed that imput be accomplished by dis- 
playing on the CRT the categories of information required for each coin, 
requiring the operator to fill in the appropriate blanks. For subsequent coins | 
in he cue general sequence, the operator is required to change only those 
ha ate the coin record which are discreet. The computer then stores a com- 
plete record for each coin. The method for accomplishing this time-saving 
input was demonstrated to our RPS eh ceben: In addition we participated in a 
variety of on-line inquiries demonstrating the speed of the Prime 400 at 
sorting data as well-as methods of data search. 

Finally, while at Axxess, we discussed Prime maintenance agreemerts and 
the company's service history. Subsequently I went over the basic Prime 


maintenance agreement for the proposed CPU and peripherals with Bob Hasel, 


sme 


Prime's Manager, Field Engineering for the New York region and have been 
satisfied as to their service speed and reliability. 

In summary, we have pe 7 ee igdenenddatty. ioe the proposal, as 
submitted by CDS and as modified on the basis of subsequent review, describes 
a feasible hardware/software configuration to accomplish the Society's 
stated primary objective of creating a unified data base of our numismatic 
collections with on-line inquiry capabilities. ae ocdipoded system also has 
application for the eventual computerization of the library catalogue follow- 
ing completion of the reorganization project, as well as membership, 


accounting and similar record keeping functions now maintained manually. 


Recommendation to Proceed 

Since the concept is feasible, the decision to proceed will be based on 
cost consideration. We are projecting a total capital acquisition cost of just 
under $160,000 with secu operating, maintenance and programming expenses 
approaching $50,000 per year. The Society does not now have any data pro- 
cessing expenses which would be offset by acquisition of an in-house facility. 
Revenues for services provided to the public are expected to be minimal. 

ne in-house system would, however, provide an accurate, indexed and 
manipulable record of the Society's holdings which does not now exist, and 
which will facilitate recording of future acquisitions in a manner consistent 
with modern museum practice. It will. give'us the capability to recall immedi- 
ately all information known about any given acquisition and even enable the 
reconstruction of accessions whose components are scattered throughout the 
collection. 

The record will not provide a capability to identify duplicate or dis- 
posable material which does not now exist; but by serving as an auditing 


device it will significantly increase the security of the collection, and if 
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necessary permit the physical rearrangement of certain extraordinarily 
valuable concentrations of coins while retaining their accessibility. 

An eauakly significant benefit will be easier access to our holdings, 
which will improve both the speed and the quality of our service to the 
general public and the scholarly community. We can certainly anticipate 
greater utilization of our holdings as a result of this easier access, both 
on and off ie arenione: This in turn will encourage volunteers to assist 
in refining out records in specific areas of their expertise. The teorented 
ability to define the strengths and weaknesses of the Society's collection - 
even to generate "want lists" if this is thought desirable - will provide 
the opportunity for a new kind of relationship with our donors which will 
ultimately work to the Society's benefit. 

At the scholarly level, the curatorial staff will be able to devise and 
perform projects which cannot now be per tieccs manually, and perhaps ulti- 
mately to integrate the Society's records with those of anes institutions 
elsewhere. The result would be a vast reduction in the time-consuming labor 
of assembling data, and greater scholarly productivity. 

Should the decision be taken to proceed with acquisition of the system, 
we would want to meet with the principals of CDS to discuss matters of pro- 
edn responsibility and schedule. From this meeting we would prepare a 
written agreement which would provide the basis for the acquisition, testing 
and installation of the system. It is reasonable to estimate that the system 


could be operational within one year. 
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ANS PRIME SYSTEM 


Capital Costs 
Acquisition: 

PRIME system, per proposal as modified to 
include Model 400 CPU and 300 MB Disk Drive 
and total of 3 ADDS Regency 25 CRT units 

300 MB disk pack plus backup 

Voltage Regulator 

Shipping 
Total Acquisition 


Site Preparation: 


Construction, electric and air handling 
Cable runs for CRT units 


Total Site Preparation 
Contingency: 


Hardware (10%) 
Application Software Development (502) 


Total Contingency 


Total Capital Costs 


FINANCIAL DATA 


$ 124,800 
2,200 
1,800 

800 


$° 129,300 


$° "19,900 


$: -158;700 


Estimated Operating Costs 


Year 1 2 3 a 2 
Personnel: 
Operator 1 - Salary, Taxes, 
Benefits (note 1) S 232.9 Saree S244 ,665." 8: 17907538 18,475 
Operator 2 - Salary, Taxes, : 1 
Benefits 12,575 Lavoro 14,665 
Programming - Revisions 
and Additions (Note 2) 1,000 2,400 2,400 8,000 8,000 
Operations: 
Electric - 9 KVA 2420 25420 2,940 3,275 3,430 
Supplies (Note 3) 2,160 PAP 2,520 2,720 2,950 
PRIME Maintenance 
Agreement (Note 4) | 9,000 12,000 12,960 14,000 15,120 
Annual Operating Costs = 39.830. 346,600 SSS bOO 5. GW. 97 OB AF O75 
Av. /month | 3,319 3.3883 4,179 3,748 3,998 
Annual Operating Costs, 1 operator 27,255 34,025 35,485 
Av. /month 2,271 2,752 2,957 


Notes 


1. Based on starting salary of $195/wk and 8% annual increments. Operator 2 is hired only 
for the initial imputting stage; Operator 1 is proposed as an additional staff position. 


2. Based on rates quoted in proposal for CDS personnal. Amounts for years 4 and 5 
anticipate added software*®for library and accounting functions. 


3. Supplies include paper, print ribbons, magnetic tape, incidentals. 


4. Maintenance contract begins after initial 90 day warranty period. 
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1.0 INTRODUCTION 


1.1 PURPOSE OF PROPOSAL 

This proposal results from the completion of the general systems analysis and 
preliminary hardware evaluation phase of a search for a computer based coin 
cataloguing and research facility, conducted by the Corporation for Distributed 


Systems (CDS). 


1.2 GENERAL CONSIDERATIONS AND RECOMMENDATIONS 

The actual data processing functions required by the ANS application are 
fundamentally identical to most other business applications, but the amount 
of data storage required, the data variability, and the many dave the data 
must be accessible make the ANS project unique from both hardware and 


software perspective. 


Few micro processor systems offer disk storage peripherals that meet your 
requirements, and many mini computer systems that do meet the requirements : 
are too expensive, have not established a reliable reputation, or do not 
offer software suitable to your application. While a micro processor system 
could be designed to meet your application requirements, there would be many 
disadvantages to such a solution. Presently, there are no single source 
micro processor systems available with the required hardware that meet our 
reliability requirements. Therefore, we would have to configure a system 


using equipment from several vendors and design and build hardware and software 


to integrate the equipment into a final system to support your application. 


The complexities of such a project are difficult enough, but, more importantly, 
the disadvantage of such an approach would be the inflexibility of the final 
system. It would serve only the very specific and limited application to be 
defined expitelty in Phase II of our methodology. Additional applications could 
not be added, nor could the existing data base be altered without a great deal 
of work on our part. Data content, keys, and indices in the existing data base 


would remain the same for the life of the system. 


On the other sd, hardware and much of the software needed for your application 
is available, tried and field proven, from a mini canal oe vendors. We 
feel that the higher cost of the hardware for such a system is far outweighed 
by lower software development costs and a much more flexible final product. Such 
a system would be suitable for addition of new applications in the future, and 
the existing data base could be changed without incurring impractical kane: 


New data fields, keys, indices, and reports could be added to the system with ease. 


We therefore recommend that a mini computer based system approach to your appli- 


cation would prove to be a much more viable investment for now and the future. 


2,0 SYSTEM OVERVIEW 


2.1 INTRODUCTION 

CDS has prepared the following system en bee in order to qualify the proposed 
system. It may be helpful at this time to point out the appendix A at the end 
of the proposal, listing a number of terms and words used in this proposal. The 
application baseline design consists of the functional diagrams, files lists, 
and module descriptions, and will apply generally to either a micro processor 
or mini computer system, regardless of vendor. CDS will warrant the software 
developed for 310 days from date of acceptance, and during the warranty period, 
CDS will correct free of charge any errors found. CDS will guarantee that the 
software will meet design requirements,. and will perform according to design 


specifications, 


After the warranty period CDS will maintain all software developed, and will 
be available at normal rates for modifications to existing software, or develop- 
ment of software for new applications. ANS will receive from CDS complete source 
code and MBean ke raon for applications program to facilitate future software 


development by others at discretion of ANS. 


2.2 APPLICATION BASELINE DESIGN 

The diagrams on the following pages depict the fundamental or baseline design of 
your application requirements by a technique known as functional decomposition. 
By " functional decomposition" we mean the isolation of separate processes into 
groupings by related functional intent. We feel that this type of presentation 
answers best the "What" of systems analysis and leaves the definition of pro- 
cedural flow within these functional constraints until Phase II, Detailed 

System Design. Following the diagram is a short description of each functional 


component, 


2.2.1 FEES 

All of the components or modules depicted on the preceding pages manipulate 

data from the following two major files: 

* ACCESSION HISTORY FILE 

This file will contain all information now entered in the 
accession journals, minus detailed information for individual 
coins, which will be contained in the coin catalog file. The 
details of actual data to be stored will include: accession 
number, date, general description of coins in accession, previous 
collections, from whom, cost, seve of accession, and number 


of objects. (See section 3 for details on contents of this file). 


* COIN CATALOG FILE 
The coin catalog file will contain all detailed information for 
the entire ANS collection of coins. (See section 3 for details 


on contents of this file). 


~“ 


2.2.2 FUNCTIONAL DIAGRAMS 
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2.2.3 MODULE DESCRIPTIONS 


* SYSTEM MAINTENANCE 
This fidcotoial ipeaeaten will provide for all system and data file 
maintenance. Programs will allow addition and deletion of keyed/non- 
keyed data fields to be stored with each accession record or coin 
description, optimization of disk storage usage, backup of data to 


tape and reloading of data from tape in event of disk failure. 


_* DATA ENTRY 
This sub-system will provide for data entry and validation for all 
information destined for one of the two major files, accession history, 
and coin catalogue. (See section 4 for details on actual format of 


CRT screen for collection of data). 


* STANDARD REPORTS 
This sub-system will provide for generation of all standard reports 


including master accession and coin listings for each department. 


* INQUIRY 
This sub-system will provide the administrative inquiry and research 
facility into the data base of coin descriptions and accession 
history. It will allow a trained operator to perform "searches" of 


the coin catalogue based on entered selection criteria. 
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2.2.4 MENU TECHNIQUE 
The proposed system is envisioned for the most part as a menu driven appli- 
cation which will make operation extremely easy to learn. The main menu 


would appear something as follows: 





ANS 
MAIN MENU SYSTEM SELECTOR 


a3 SYSTEM MAINTENANCE UTILITIES 
pe DATA ENTRY 
3 STANDARD REPORT GENERATION 


4 DATA BASE INQUIRIES 





The operator would select the desired sub-system by typing the appropriate 
number, and another menu would appear, providing for more specific selection 


within the sub-system chosen. 


The specific data entry programs within selection 2 would function a little 
differently, but are designed to be easy to learn and operate also (see section 
4 for details). The inquiry sub-system would be different from menu selection, 
allowing for entry of English like sentences specifying search criteria and 


report output format (see section 7 for details). 


so 


2.3 GENERAL HARDWARE CONFIGURATION 
As a result of our general systems analysis, the proposed system will contain 
the hardware components described below. These components will be the same for 


either a micro processor or mini computer based system. 


* - CPU AND MEMORY - PRIME 400 
Our analysis indicates that the CPU will have to be powerful sneak 
to provide for reasonable performance in the INQUIRY sub-system, and 
we estimate a need for at least 256 KB (kilo-bytes) of memory for 
efficient operation of your bop licatios., A major part of the available 
memory will be used to hold the file indices. (These file indices must 
be held in memory for efficient data base searches, and will be very 


large due to the large number of records in the data base). 


* DISK STORAGE UNIT - PRIME 300 MB 
Our analysis indicates a need for approximately 250 MB (million bytes) 
of disk storage based on the estimated number of accessions and coins 
in your catalogs. The Prime 300MB disk storage unit is almost the same 


price as the 80MB. 


* MAGNETIC TAPE UNIT 
Our analysis indicates that for your application, it is imperative to 
provide adequate backup for the major data files, so that no data will 
be lost in the event of a disk malfunction. The tape unit will be used 
primarily for backup and may possibly be used oe storage of some of 


the "free text" associated with coin descriptions. 


* PRINTER 


The printer will be used for output of standard reports and inquiry 
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results. Our analysis shows that the printer would have a relatively 
light work load with the excaption of yearly master lists, therefore 
we recommend a 200 CPS (characters per second) printer. A slower 

printer would make production of large reports require literally days 
of print time, and performance of such a printer would quickly degrade. 
Faster additional printers can easily be added to a mini computer 

system later if the need becomes apparent. Reports can be produced on 


tape for conversion to hard copy by service bureau high-speed printers. 


CRT - ADDS REGENCY 25 

The CRT's will be used for data entry and research, Three units are 
included in the initial configuration. The performance characteristics 
of a given hardware configuration are complicated to assess at best, 
but will always degrade with sddivion of more terminals. The PRIME 400 


is designed to accommodate up to sixty-four (64) CRT's. 


es 


3.0 DATA BASE REQUIREMENTS 


ie: INTRODUCTION 


This section addresses the information storage requirements for your application. 


This refers to the fields or data to be stored in each of the two major files, 


and includes a preliminary list of fields that should be keys. The analysis of 


disk storage requirements is based on the following four (4) types of data 


required by your application; 


i a 


TABLE LOOKUP 

This storage technique is used for data fields that have a limited 
number of unique values, such as coin material. Instead of storing 

the field 'silver' in each record where appropriate, a code value of 
'1' would be stored which, when looked up in a table would expand to 
the actual meaning of the code. Application of this technique where 
applicable can save literally millions of bytes of storage. A practical 
limit for the number a unique values a field of this type may have 


is sixty four (64). 


FIXED SIZE FIELD 

This type is used for fields that will have too many unique values for 
type I, but which can practically be limited to a fixed number of 
characters (bytes). As an example, consider the field 'mint'. There 
are far too many different (unique) mint names to use type I, however 
most all mint names could be stored in a twenty (20) character fixed 
size field, and those that are longer could be suitably abbreviated. 
Numeric variables that are too large for type IV are stored as this 


type of data, and also decimal numbers such as 'price'. 
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III. VARIABLE LENGTH TEXT 


IV. 


This data type will be used for information which may vary in length 

from one (1) to sixty four (64) lines of reeeoal information. An example 
of this data type would bates acquired’ in the accession history file. 
This textual information would be stored unchanged in the system, but 

the actual means of neces to it would be through a list. of keywords 
specified separately, but contained within the text. For example, a coin 
with a subject of Pliny the Elder might have thirty or forty lines of text 
describing the content of the coins surfaces, and list of keywords. in- 
cluding Pliny; Elder; Roman; poet; writer, etc. Any time a search inquiry 
specified 'poet' as one of the selection criteria, this coin's record would 
be selected and all information about it, including all of the text, would 


be available for displaying to the terminal or printer. 


NUMERIC 

This data type will be used for fields that are strictly integer numbers 
(whole numbers like 1234 and not decimal like 1.234). An example of this 
data type would be ‘dates’. The following tables summarize the data fields 


to be stored in the two major files, their type and size where applicable. 


An, .estimate of the storage requirements for the application can be made 
from these tables as follows. For the accession history file, assuming a 
limit of about ten lines of free text associated with each accession re- 
cord, the application would require about 1000 characters per accession 
record. Our analysis indicates that since 1938, you have acquired about 

250 accessions per year which gives approximately 10,000 existing accession 
records. This works out to about 10 MB of storage for the accession file. 


For the coin catalog, a little bit more complex approach is required. Our 


Lé 


_ Study indicates that perhaps 10% of the coins will require complete and 
detailed descriptive information, another 10-152 will have some detailed 
information, and the rest will have type I, II, and IV fields entered, 

but little free sents Based on these estimates, the storage requirements 


for the coin catalog file break down to the following; 


10% of 1,000,000 coins X 1000 characters ea. = 100 MB 
10% of 1,000,000 coins X 400 characters ea. = 40 MB 
80% of 1,000,000 coins X 100 characters ea. = 80 MB 


Note that these are generous estimates, and it is our opinion that there will 


be relatively few coins that require the total 1000 characters to describe. 


In addition to the actual data shown in the tables, there will be some 
additional overhead storage requirements for system and application programs, 
indices for key fields, and other minor things relative to the requirements 


for the two major files. 


Our study shows that it would be a definite advantage to have all informa- 
tion on all coins ‘on line’ and available to the computer at all times, 


¢ 


because of the general nature of research problems. - 
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ACCESSION HISTORY FILE 





PTE MAME er TYPE eat ee ee 
-. ACCESSION. NUMBER Le 12. (plus. decimal points) 
GENERAL DESCRIPTION Trii 80 

















Benge Eis 80 

ee sage Sea as) A a 40 

ae ¥ orcad 

ner 3 : 

does IV 8 ae 
foie *1 rR EG 80 

a en 

ee eee IV 5 





| *1 Includes how acquired, remarks, keywords; can point to hard copy files. 
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3.3 COIN CATALOG FILE 





Re a Romer 
“AMSTITUTION (ANS, AA, ete) 1 ie tS 
ok scab phe ng ee Gee eee ee 
ap RUNCU UN AE pee eda Ole) re me 
Pen See are es ee ae 
i SEREES  (Sypesty pation, ete) sd eh 
pie ME DERLES AUREL s BEC. : ae 
DENOMINATION. Ir 
MOY ae ee ie 
Siac aah Atel oe ce oe MA cg ae 
Na a OO ee peed 
rh tas et ee Ue 
ipl ake Calaecnamiaim ke” Matte are 1 oo 


... WEIGHT (g) 


-- DIMENSIONS 


‘SHAPE 


II : 
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IV 


IV 


IV 


80 


ae: 


each 


each 


3.4 


All fields within 


pected 


MANUFACTURE 

DIE AXIS 

ANALYSIS (composition, condition) 
PUBLICATIONS 

OBVERSE TYPE 

REVERSE TYPE 

OBVERSE LEGEND 


REVERSE LEGEND 


INDICES OR KEY FIELDS 


heavy use during inquiry searching. 
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Edd 


a G8 


Lid 


Lit 


je 8s 


Lid 


1 (12 pts of the clock) 


80 


80 


80 


80 


80 


80 


each file should be defined as key fields because of their ex- 


4.0 INPUT REQUIREMENTS 


4.1 INTRODUCTION 

This section deals with the requirements for entry of data into either of the 

two major data files and presents sample screen formats. Data entry will be 
accomplished by a technique known as ‘formatted screen input'. This technique is 
much more productive and easy to use than a query/response technique where each 
data field is prompted by a line display and requires operator response for each 
query line. In this technique, the CRT screen is 'painted' with a format of labels 
indicating the names of the fields to be input, and the eperakor inputs each 
field beside the appropriate label. All information can easily be seen by the 
operator at all times, and each field can be verified as to it's validity (e.g. 
alphabetic characters will not be accepted in a numeric field type). The operator 
can move the cursor around through the fields via keyboard special function keys 
and edit the data before "releasing' it to the computer for validation. In the 
case of validation errors, appropriate error messages will appear on the CRT to 
indicate the field in error, and the operator will then be allowed to correct 

the field. Once a screen of data has been accepted as valid by the computer, it 
will be possible to clear only part of the data displayed before the next entry 
to facilitate entry of data for which many fields will have the same value, 
thereby increasing operator input efficiency. The screens shown are only samples 


and do not necessarily depict the final screen formats to be used. 
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4.2 ACCESSION DATA INPUT 


ACCESSION NO. 
FUNDING COST VALUE 


GENERAL DESCRIPTION ae Oe eas 





GENERAL TEXT 


KEYWORDS 
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4.3 COIN DATA INPUT 
Coin Data input screens would be very similar, but probably broken up into 
two screens, one to collect type I, II, and IV data field types, and another 


to allow entry of free text and keywords. Samples of these screens are not shown. 


4.4 INITIAL ENTRY 

It is anticipated that initial entries will be made concurrently in the accession 
and coin files. A special problem extane at the ANS because approximately 225,000 
objects lack preassigned accession numbers (the link between the accession and 
coin files): CDS will develop the program to segregate this class of objects to 


facilitate matching of the accession and coin records. 


A flow chart of the entire initial entry procedure will be constructed as a 


guide for ANS personnel. 
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5.0 PROCESSING REQUIREMENTS 


5.1 INTRODUCTION 
This section addresses the general processing requirements of your application 
related to the major functional areas of data collection, searching, and report 
formatting. Our analysis indicates a general need for flexibility to change, and 
efficient processing of data base inquiries as major considerations. Ease of 
operation and maintenance are always objectives, especially significant in this 
case since there is a definite possibility of un-trained ANS visitors using the 
system. These requirements refer not only to the hardware performance needs for 
your application, but also to the software programs. 
* Purchased General Solutions 

This would be packaged software that has been developed by another 

vendor, and if carefully selected, can be more comprehensive in 

pe ilbeniknee and less expensive than developed general software. We have 

evaluated several packages software inquiry and reporting programs 


that we believe offer a favorable cost/performance result. 


5.2 DATA COLLECTION 

Because of the initial entry task, we see a need for what is commonly called 
"formatted screen data entry’. This technique is described more completely in 
section 4, and provides an easy to use and efficient means of getting into the 
system the data you already have in one form or another. There is a requirement 
for flexibility in these screen data entry modules, in that you may be altering 
the data base contents as you become more familiar with the capabilities of the 
system. There is also a requirement to be able to add additional screen collection 


modules for new applications that may be added in the future. 
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5.3 DATA BASE SEARCHING 

The software that provides for inquiry and reporting of the data base contents 
must be very efficient, flexible and easy to use. This is the most critical 
aspect of the entire application. It should provide access to any and all fields 
of information in both of the major data files, whether these fields are key 
fields or mary As pointed out in section 7, searches based on non-keyed fields 
will require a sequential search of the entire data base and will therefore 

take much more time than searches of keyed fields. While these types of searches 
will take longer, they must be available; in other eosae the difterencn aneats 
be measurable in hours at the most. For example, a search that involved several 
non-key fields might be a one time report, but should be producable in several 


hours of processing time. 


5.4 REPORT FORMATTING 

The requirement for flexibility extends to the facilities for formatting reports 
of inquiry results. Users of the system should be able to format a report con- 
taining whatever information is desired with ease in a short amount of time 


(see section 6 for more details on reporting requirements). 
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6.0 OUTPUT REQUIREMENTS 


6.1 INTRODUCTION 
This section identifies the requirements for output from the data base to 


CRT screens, hard-copy devices (printers), and machine-readable format (tape). 


6.2 STANDARD REPORTS 
Our analysis has identified at this time the following requirements for output 
which we will refer to as ‘standard reports’. This means that they will be 
readily available by selection from a report menu. These standard reports include; 
* ACCESSION HISTORY REPORT 
This report will show any range of accession history records by 
accession number, and will include all fields related to the 
accession history file, but not detailed coin descriptions from 
the coin catalog file. 
* MASTER LISt 
This report will be the ‘master listing" of all information in 
both data bases; accession history and coin catalog. 
Variations of these reports will cover most conceivable requirements by providing 
options on printed sort order. For example, one report may be by ascending 
accession number and another by department names with accession information 


ascending within each department. 


6.3 INQUIRY REPORTS TO CRT, PRINTER 

The most significant requirement for display of inquiry results to the terminal 
and printer is that a user be able to easily specify a report's content and 
format in columar fashion. Page headings, column contents and titles should 


all be controllable by the user. 
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6.4 VIDEOCOMP OUTPUT 
Output from the data base should be formatted for composition by computer- 
driven photo composition equipment. Data entry procedures will include 


assigning tags designating typography and diacritics. 


28 


7.0 INQUIRY REQUIREMENTS 


The inquiry requirements refer to CRT oriented research into the data base of 
accession and coin information. This facility would be simple to use and easy 

to learn. It would also provide as completely as possible a flexible and general 
tool. Users must be able to desoethe to the computer system in English like 
sentences the parameters and selection criteria desired for a particular inquiry, 
as well as output report format specifications if desired. It must default to 
some standard output format when the user does not wish to specify it. It must 


provide an effective research tool for all users from simple to sophisticated. 


Specifically, the above mentioned requirements make the task of developing such 
software very complicated, time consuming and expensive. There are several 
packaged inquiry systems available for the proposed mini computer, and they meet 
aieet all the requirements outlined. These packages are available for much less 
then we could develop similar software, and are field proven and necessarily 
completely flexible. This sort of packaged software could be utilized for 
additional applications to be added to your system in the future. It is our 
opinion that a suitable package be selected to fulfill the inquiry requirements, 


and we are currently evaluating several other available packages. 
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8.0 APPLICATION DEVELOPMENT SCHEDULES 


8.1 INTRODUCTION 

The following schedules show i general the tasks to be performed for completion 
of the project on a mini based system. These schedules will vary some after 

the completion of Phase II, Detailed System Design, but are accurate nels 


for the cost comparisons shown in section 4.0 COST ANALYSIS. 


These schedules do not reflect actual elapsed time for completion of each 
task, but rather only total hours required to accomplish each task. A detailed 
time schedule will be developed during Phase II of the project, and enforced 
through our project progress reviews. Application software design and coding 
time requirements may vary with selection of specific equipment and packaged 
software. This aspect of the project is difficult to estimate at this time, 


and it should be realized that it could vary as much as fifty percent (50%). 
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8.2 MINI COMPUTER BASED SYSTEM 


TASK LIST HOURS 





SELECT AND INTEGRATE HARDWARE (AXXESS) 160 


eee eee es es eS ES NY SE SND GS Se Gey SED Smee eee US ee eS SUP GENT ae EEN eee SESS SNS ORS Mees CEN ee SS ED eS ER eee Ree SS eS eee EE RS SD EE GS Sey SS Gs ES SENS ES SS OS EE ES SS SS SS ee Se So Se eT Se ee Go 


SYSTEM MAINTENANCE 80 
PUMA COLLECHION 0 Se eee ee ee 
5 yeponn emieanton 9 a 
P mont ee de er tee 
SsrmMrSNG ye ee 
eecuerivce pusTING. 5, poe ee ae ee 
ON BUTE GNSPALLATION® (PRIMEY. 3, 0 Mo ER gag 
epee tioné voligy Uae Gk a a gry, 
FINAL DOCUMENTATION AND PROJECT CLOSURE = itt 
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9.0 CONVERSION CONSIDERATIONS 


9.1 INTRODUCTION 
The conversion from your current manual system to a fully computerized system 
will proceed as follows once the final equipment configuration has been 


selected; 


a. CDS to consider developing software at Axxess office to avoid 


transhipping ANS system (most damage occurs during shipping). 


b. While our staff is developing the application software, CDS will 
guide ANS in preparing your site for installation of the computer 
system. This will involve physical preparation for security, 
environmental wankege power supply conditioning (if necessary), 
and supplies acquisition for such items as printer paper and ribbons, 
etc. Prime field engineer will consult and provide ANS written 


approval of site preparation prior to installation. 


c. Once the system has been completed and accepted by ANS, it will be 
shipped to ANS, and CDS, under the direction of Pima. will install 
. it on your site with trained vendor personnel available to unpack and 
connect the hardware. The vendor personnel will perform hardware 


acceptance testing to ensure that it is all functioning properly. 


d. With the hardware installed and checked out, CDS will then install 
the applications software and begin ANS personnel training. CDS will 
remain on site until the "system’ is functional and initial data 


entry is under way. 


Se 


e. CDS will remain available free of charge for the warranty period 


to correct any problems discovered with our applications software. 


f. CDS will warrant. acceptance for service by Prime of entire ANS com- 
puter facility, including all peripherals, under initial manufacturers' 


warranties and through issuance of a standard Prime service contract. 


9.2 SETUP AT ANS, PHYSICAL REQUIREMENTS 

The proposed system will require approximately 170 square feet of floor space 
(ca. 8 x 21) in a room with at least 8 feet of ceiling clearance. The equipment 
will present about 1500 to 2000 pounds of load on the floor structure. The 
environment must be controlled generally within the limits of 50 to 90 degrees 
Farenheit and 30 to 80 percent relative humidity. The power supply must consist 
of a combination of 15, 20, and 30 amp outlets at both 120 and 240 volts alter-. 
nating current. Heating, ventilation, and air conditioning will have to handle 

a load of approximately 12,500 Btu/hour, 1 ton of cooling capacity. When 

specific hardware has been selected, CDS will interact with the vendor to outline 


specific physical requirements necessary for installation of the equipment. 


9.3 PERSONNEL TRAINING 

While there will not be a need for ANS to Praetde a dedicated operations staff 
for the proposed system, there will be specific responsibilities associated with 
operation of the system that must be assigned to someone. These responsibilities 
pertain to daily power up and down procedures, general weekly cleaning and main- 
tenance of the equipment, interfacing with CDS for solution of problems, and 
resolution of usage conflicts, to name a few. CDS will be on site for about two 
weeks during installation of the system at ANS, and will hold numerous classes 


to provide complete orientation training for all ANS personnel. This will include 
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management, operations, data entry, and research personnel training. 


9.4 INITIAL ENTRY OF EXISTING DATA 

The initial entry of entattde accessions and coin descriptions will be an on- 
going task for at least 3 years. Predictions for the time required are rough 
estimates now, but based on a estimate of thirty (30) seconds per coin des- 
cription, it will take about three years to enter descriptions for all 1,000,000 
coins assuming two persons working 6 1/2 hours a day. The estimate of thirty 


seconds per coin is a guessed average, 
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10.Q0 ADDITION OF OTHER APPLICATIONS 


10.1 LIBRARY DATA BASE, ACCOUNTING, PAYROLL, ETC, 

The Prime system is a true general purpose computer accommodating any number 
and variety of applications, limited only by performance constraints of the 
system. Creation of a data bee eect en for cataloguing the library collection 
is anticipated during years 4-5. Campbell estimates that the catalogue revision 
project will be completed in 1985 at which time conversion of the card file 


could begin. 


Conversion of the accounting records is estimated on the basis of limited 


modification of prepackaged applications software. 
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11.0 COST ANALYSIS 


11.1 INTRODUCTION 

Due to the potential for variance in software development requirements, CDS 
would propose a Time and Materials rate of $30.00 per hour for the Project 
nce and $25.00 for the analyst/proseammert All software cost estimates 

are based on these figures. 

11.2 MAJOR COST COMPARISON TABLE 

In addition to the breakdowns below, . the Prime mini computer systems will 
require installation of heating, ventilation and air conditioning equipment. This 
equipment will cost $7,000 to $10,000 depending on exact requirements of final 
hardware selection. There may be a need for device that ensures a clean, consis- 
tent power supply if the standard service in your area is subject to fluctuations 


or frequent failures. The cost of such a device will be in the range of $1,500 


to $2,500. 
EQUIPMENT OR SOFTWARE poe (ss ns ss PRIME. (See budget) 
Bi 5c Rn? iS SIME LOIN ig AU ARE ue empoemmar ne 207 
CPU AND MEMORY $37,100 
DISK 28,500 
‘TAPE | 12,000 
PRINTER 4,000 
CRT | 2,000 
PURCHASED SOFTWARE *1 5-12,000 
APPLICATION SOFTWARE *2 14,000 
TEST, INSTALL AND DOCUMENT | 5,240 


*] This will vary depending on final selection of available packaged 
software. We are currently evaluating a package available for the PRIME 
system, and have others to evaluate. 


*2 The cost of application software develop will vary depending on packaged 
software selected as well as the final hardware selected. It could 
vary as much as +5024. 
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11.3 OPERATING COSTS 

There are a number of operations costs summarized below, and these are estimates 
as well. Power refers to electricity for the computer as well as the environ- 
mental control equipment. Supplies refer to such things as paper, printer ribbons, 
tapes, and so on. Maintenance refers to contracted support for the computer 


hardware. 


OPERATIONS COSTS SUMMARY 
(MONTHLY ) 


1980$ (See budget) 


POWER | $ 210 
SUPPLIES 186 
MAINTENANCE 1000 
TOTALS $1390 


11.4 TOTAL COSTS SUMMARIZED 
The table summarizes the capital investment costs for the mini cumputer 


system. 


PRIME 
HARDWARE $ 83,600 
SOFTWARE 27,240 *1 
TOTALS $ 110,840 (See budget) 


“*1 = based on estimate of $8,000 for packaged software in Prime system 
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12.Q0 EXECUTIVE SUMMARY 


The mini computer system proposed by CDS will feature the ability to immediately 
enter into the accession history file new accessions as they are acquired, 
sroviltig (munky and accurate accountability of ANS's activities. Entry of 
detailed information pertaining to individual objects can be accomplished by 
staff members or users as work in specific areas of the collection progresses. 
Administrators will be able to quickly respond to inquiries concerning the 


ANS's history of accessions from the first to the most recent. 


Staff members and users of the ANS collection will benefit from research 
facilities making possible inquiries that are now impractical because of time 
considerations. These facilities will provide results to research questions in 

a few hours that now require weeks or months. Ail of the ANS personnel and users 
will benefit from a single computer facility centralizing any and all information 
about accessions and objects. 

The advantages of a mini computer over a micro computer all derive from the 
flexibility of the final mini computer based system. As new accountability and 
research needs become apparent, the mini computer system will allow the addition 
of new data fields, keys, indices, reports, and inquire methods to meet these 
needs. If new applications become desirable, or data storage requirements for 
the proposed System grow, the mini computer system will allow addition of larger 
disks, faster printers, and more CRT terminals. The mini computer system will 
nee and grow with ANS. Staff members will be able to develop their own 
programs in BASIC for specific use of the coin data base, an advantage which 


we believe will become more significant as familiarity with the system increases. 
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On the basis of our analysis and evaluation, CDS recommends that a mini 
computer be selected for the development of aoe application. If this is in 
accordance with your budget and plans for the future, we would be eager to 
begin Phase II of the project, detailed design of application software and 


selection of a specific mini computer. 
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APPENDIX A 


GLOSSARY OF TERMS 


Application software 


These terms refer to the programs that relate specifically to your 
application of the computer to ANS activities. 


Bit 


Byte 


Word 


These terms all refer to units of measurement for the computer's 
memory and disk storage capacities. One bit refers to one binary digit 
of information (0 or 1), eight bits make up one byte, and two bytes 
make up one word. | 


8 Bits 22) Byte 
16:Bits = 2 Bytes. =. 1. Word 


Byte 


A byte is the term that refers. to the computer storage required to 
hold one character of information, where a character is any letter 
of the alphabet, number, or special character (*&#%,. etc.). It is 
used. ..as*:a ‘unit «of measurement ..for the .computer’s ‘memory and 
disk capacities. Abbreviations of terms often associated with 'byte' 
are K: for -one thousand bytes. (1KB = 1000. bytes), and MB for: one 
million bytes (1MB = 1,000,000 bytes). 


Cursor 


The cursor is the blinking underscore character that appears on the 
ert screen to indicate position. Used in formatted screen data input, 
it indicates which field is being entered and moves through the format 
to allow entry of data ina specific order. 


Data Base 


wo. teem referring:.“to “the (sum total: of. all. information: “etored in 
whatever .manner in: the computer system. In your application, it is 
used 40 refer to all information contained in. both ‘thé: accession 
history file and coin catalogue file. 
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File 
Record 
: Field 


These terms refer to a heirarchy of information LEVELS: & Tile is 
a group of related records, each record containing the same fields. 
The following depicts the relationship of these terms. 


Coin #1 : Description,.., Mint 
Coin #2 DESCriptiony «x4 Mint 


RECORD 


#12345 Description,.., 





Coin #n Description,.., Mint 


Iindices*on Key Fields 


The term further qualifies a data field. .as:a special type. It differs 
from other data fields in that it is stored and accessed differently. 
The primary reason for making a field a key is because it is expeced 
to be used heavily in inquirys. A key field can be processed or 
searched much faster that a non-key field. There is an additional 
Storage requirement involved with a key field, and that is why a data 
base is not all key fields. . 


Key Words 


Refers to specific words within free text that are meaningfull. These 
special words will be treated similar to key fields in that they will 
be available for searching within the inquiry sub-system. 





¥ 
er 


Menu 


Refers to a table of selections specified .by entering a number or 
letter. A menu driven system is easier to learn and operate because 
all of the given application's options always appear on the screen 
for reference. The operator: does not. have to. remember. any 


- abbreviations of -program names, they are.simply selected from _ the 


list appearing in the menu. 


Systems software 
The programs that are required to use the computers hardware devices 


for solution: of your application.: Your application. software will 
actually use : the. - systems software. 
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